One of the objectives of a safety-relevant or safety-oriented system is to guarantee a reliable and correct functioning of software components which are involved in safety-critical functions.
When a safety function is executed its reliability and correctness can be influenced by the occurrence of errors. Typically errors such as random hardware faults or systematic design errors can occur in such cases. A possible defect in a processing unit could be cited as an example of a random hardware fault. This produces a malfunction which adversely affects the handling of a device (e.g. of a vehicle) in which the processor unit is employed. Possible design errors can occur even during the development phase because of incorrect implementation of the specification (e.g. modeling or planning). Such errors and similar errors can have serious consequences in safety-relevant systems.
If the transport area (e.g. railways or aircraft) is considered as an example, such errors can typically lead to a system or a device (of a vehicle for example) becoming unmanageable, with the concomitant serious consequences for the passengers. Nor is a permanent adverse effect on the environment beyond the bounds of possibility.
To ensure functional safety at least one safety requirement is generally specified for each specified safety function, in order to achieve and/or to fulfill a predetermined safety level. Functional safety is then seen is being provided if each specified safety function is executed and for each safety function a desired level of fulfillment is achieved in accordance with the corresponding safety integrity level. It should be noted here that the safety integrity level (SIL) is a property of a safety function and does not relate to a system or to a subsystem. This safety function is realized through a combination of systems however, which consist of software and hardware components. The safety integrity system thus relates to an end-to-end safety function of a safety-related system.
Like every other component of the safety-oriented system, a software component does not have any Safety Integrity Level (SIL) if it is considered in isolation from a safety-related system. If the software component is integrated into a system, the software component can be suitable for supporting safety functions for a specific SIL. This depends on how the software component was specified, developed, implemented and/or verified.
The software safety integrity level n or SSIL n is specified as follows: Software which has been developed using appropriate techniques and measures, with the techniques and measures ensuring that the software meets the requirements for systematic failures of a specific safety function X for SSIL n.
Thus a software safety integrity level is not a property of systems, subsystems or components. The above specification can be interpreted such that the software system, software subsystem or the software components can be used at integrity levels up to SSIL 1, 2, 3 or 4. This alone is not sufficient however to establish a safety function for the required SSIL. The software safety integrity level of a subsystem determines the highest SSIL which can be made to apply for a safety function using this subsystem. The enabling or the usability of a subsystem for SSILn (with n=1, 2, 3 or 4) is achieved if the SW subsystem fulfils the requirements of prespecified safety standards (e.g. IEC 61508, EN50128 etc.).
Furthermore product-liability is also an important aspect as far as safety-relevant or safety-oriented systems are concerned. If a (purchased) product is faulty, under some circumstances claims for damages can also be made. The manufacturer can deny responsibility for the damage if the fault was not present when the product was put into circulation or if the product met predetermined safety expectations and predetermined legal requirements.
There is currently no legal standard in the European legal system which imposes mandatory requirements on the electronic systems in relation to checking their fault safety or functional safety. However the fact that the electronics sector is becoming ever larger and safety is consequently becoming ever more important means that an alternative was created which guarantees the mostly demanded safety of products here. It is therefore sufficient for the evidence and accordingly an approval of a failsafe characteristic of electronic systems to be available from the responsible authority, (e.g. test certification authority or railway governing board) and the manufacturer's technical service. An approval is given in such cases based on predetermined rules or standards (e.g. IEC 61508, EN50128 etc.).
Safety-relevant or safety-oriented systems having software components have safety requirements imposed upon them by the predetermined rules or standards which describe how a safe behavior of the system is guaranteed and how the occurrence of danger situations can be prevented.
The safety relevance of technical systems is derived from the maximum safety requirement on the functions made available by these systems. If one considers the use of software in safety-oriented systems, then as a rule only a small part of safety functions are taken over by the software. I.e. the software components used are to be subdivided into safety-relevant or safety-critical software components on the one hand and non-safety-relevant or non-safety-critical software components on the other hand. Since there is the possibility that the non-safety-critical software components can impinge on the safety of the safety-critical software components, i.e. they can mutually influence each other, these are developed to be just as safe as the safety-critical software components.
In this case the embodiment of a non-safety-critical software component or software function may not negatively influence the reliable or correct execution of a safety-critical software component or software function. This influencing occurs as so-called feedback. This feedback can be suppressed by an explicit separation between the function classes (safety-critical, or non-safety critical) on a system. This separation is to be understood as absence of a feedback from non-safety-critical software components or functions to safety-critical software components or functions.
The implementation of the non-safety-critical software components or functions with the same level of safety as the safety-critical software components or functions leads however to restrictions in the non-safety-critical software components (e.g. in respect of their functionality or coding guidelines) and to great expense in relation to the development of the non-safety-critical software components to be used.
Further known procedures again follow the path of separating the safety-critical and non-safety-critical software components by setting up hardware components which have either safety-critical of non-safety-critical software components. In this way a physical separation of the components is achieved. Since these components interact however, the appropriate safe interfaces must be set up. Both the design of the hardware components and also the design of the respective interfaces result in a higher outlay.
The above-mentioned known way of using software components in safety-oriented systems results in the implemented software being bound into the respective area of application. If one wishes to use implemented software in another way in order to save development costs it is generally only possible with a major effort in conversion, in which case the safety questions have to be asked and checked once more.